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PRE-VERIFICATION OF APPLICATIONS IN MOBILE COMPUTING 

Field of the Invention 

5 This invention relates to verification of application software and 

applets (generally referred to as applications) prior to running on a 
processor in a mobile computing environment, for the purposes of 
insuring that an application is appropriately authorized from a security 
point of view, whether for system security or other purposes. 

10 

Background of the Invention 

In the field of software security, it is know to create digital 
certificates for software applications. A software vendor is provided 

15 with an encryption key that permits the vendor to generate a certificate 
that has a digital signature generated from the encryption key. A user 
of the software from that software vendor can verify that the software 
has originated from the authorized vendor by checking the digital 
signature of the accompanying certificate. The certificate is typically a 

20 fixed-length "hash" of the software encrypted with the encryption key. 
The user is able to verify the signature because the user is provided 
with an encryption key from the same security domain as the 
encritypion key of the vendor, i.e. the two encryption keys share the 
same route key. The user is therefore able to verify that the digital 

25 certificate originates from the authorized security domain. 
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The process of verifying a signature of a digital signature is time 
consuming- If the signature has to be checked each time an 
application is launched or each time a new application is downloaded 
to a mobile device, the process of using the mobile device is degraded 
5 in its speed performance. This becomes particularly noticeable if a 
device is started up and, upon power up, several applications have to 
be launched and the signatures of all the applications have to be 
verified. It is a particular need in the mobile computing environment 
that time to operation upon power-up is minimized. There is a need for 
10 a faster method of verifying the authenticity of an application and 
maintaining security upon application launch, while avoiding the need 
for lengthy signature verification processes. 

There is also a need for an improved manner of enabling and 
15 disabling certificates in a mobile device remotely from a mobile 
communications network in a secure manner. 

Brief Description of the Drawings 

20 FIG. 1 is block diagram illustrating a mobile computing device in 

communications with a mobile communications network. 

FIG. 2 is a flow diagram of a process performed by an issuer of a 
subscriber identity module (SIM). 

25 
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FiG. 3 is a flow diagram of a process performed in the mobile 
communications device of Fig. 1. 

FIG. 4 is a second program performed by the communications 
device of FIG. 1 , upon receipt of a certification configuration message 
(CCM). 

FIG. 5 is a message format diagram illustrating the format of a 
CCM message. 

Detailed Description of the Drawings 

Referring to FIG. 1, a mobile communications device 10 is 
illustrated comprising a transceiver radio 11, a microprocessor 12 and 
a program memory 13. Other elements of the mobile communications 
device 10 are not illustrated but are well known in the art. The 
communications device 10 has a subscriber identity module (SIM) 15 
that is typically in the form of a miniature smart card that slots into a 
receiving slot in the communications device 10. The radio 11 is in 
radio communications with a base station 20 that has a central 
controller 21. 



Also illustrated in FIG. 1 in the microprocessor 12 is a hash code 
generator 14, a program execution process 22, a comparison element 
25 23, an encryption key register 25 and a cryptographic process 26, all 
implemented in software. Also illustrated is an application 30 stored in 
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the program memory 13. The application 30 has a digital certificate 31 
that is a "signed" hash of the application 30. Illustrated in SIM 15 is a 
list 33 of authorized applications. Further illustrated in FIG. 1 are 
certain elements of information passing from the base station 20 to the 
5 radio 11, including an application 40 and a certification configuration 
message 41. 

In operation, the mobile communications device 10 is powered 
up and applications are loaded from the program memory 13 into the 

10 microprocessor 12. For running of an application, a check is made 
against the list 33 in the SIM 15 to verify whether the application is 
authorized for running. New applications 40 can be received over the 
air from the base station 20 and stored in program memory 1 3. 
Configuration change messages 41 can be received from the central 

15 control 21 via the base station 20. Other operations and processes are 
performed that need not be described in detail. 

When a subscriber is issued with a SIM 15, a list 33 is generated 
and loaded in the SIM. The process of FIG. 2 is performed by the 
20 entity issuing the SIM to the subscnber. 

Upon commencement of the process of FIG. 2 (step 100) a hash 
is created by a hash code generator (equivalent to hash code 
generator 14) of any executable object that is to be permitted to be run 
25 on the microprocessor 12. This hash is created in step 101 by passing 
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the executable code of the object through a hash generator such as a 
SHA1 hash generator in a manner known in the art. The hash code 
generator performs a mathematical one-way function on the executable 
code that has two properties: 1) from an arbitrary number of bytes, of 

5 input, a finite number of bits of output are generated (e.g. 160 bits) 
whereby virtually no two inputs give the same output and 2) from an 
output it is not possible to discern the input. The resultant hash code is 
much shorter than the object itself, but is of sufficient length that is 
virtually unreproduceable. The creation of a hash of an executable 

10 object is also referred to as creation of an executable object 
"fingerprint". The hash used is of the same type as that used for 
signing a digital signature of a new object. 

In step 102, the hash code is stored in a protected verified 
15 application list 33 in the SIM 15. The process of FIG. 2 is executed for 
every object (application, applet or other object) to be run on the 
microprocessor 12. 

Every time a new application is launched (for example upon 
20 power-up of the mobile communications device, or upon launching of a 
new application after power-up) or upon downloading a new application 
40 to the mobile communications device 10, the process of FIG. 3 is 
executed. Upon the start of the process at step 200. and upon 
launching of the application or downloading of the applet (step 201), a 
25 hash is created of the application or applet in step 202 using the hash 
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generator 14. This hash is again the same hash as would be used for 
computing the digital signature of the application or applet. In step 
204, the hash so created is checked by comparison element 23 against 
the verified application list 33. If the hash value (digital fingerprint) is 
5 present in the list (step 206) and if the entry has not expired (step 208), 
the application or applet is launched in step 210. As a preferred (but 
not essential) feature, a counter is decremented (or incremented) for 
that application or applet in step 212 each time it is executed. 

10 If no list entry for the object is present (step 206) or if the entry 

for the object has expired (step 208) full signature verification is 
performed by cryptographic process 26 in step 220. In full signature 
verification, the hash already created is one of the inputs of the public 
key cryptographic process 26 that performs processor-intensive 

15 cryptography. If the digital signature of the application is successfully 
verified, the application is executed by execute process 22 in step 210. 
Optionally, the hash of the application is added to the list 33 (as shown 
by the dashed line in FIG. 1). If the digital signature is not verified in 
step 222, the application is not launched and the process ends at step 

20 230, ready for launch of the next application. 

It is a preferred feature that there is a maximum number of uses 
for an entry in the list 33 before that entry is marked invalid by 
comparison element 23. A preferred value of five uses is suitable. 
25 Each time step 212 is executed, the counter (not shown in FIG.1) for 
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that entry is decremented (or incremented) and when the counter 
reaches zero (or reaches a threshold respectively), step 208 will 
indicate that the entry has expired when it is next launched. The list 33 
preferably has a maximum size and a prioritization scheme is used to 
5 determine which applications to delete when the list is full and a new 
entry is added to the list. 

In the event that a new certificate configuration message (CCM, 
described below) is received by the mobile device 10, all verified 
10 application list entries must be marked invalid. Alternately, a 

mechanism is provided to determine the validity of an authorizing 
certificate entry for each application in the list. 

As a preferred optional feature, a pointer is stored with the 
15 application, pointing to the entry in the list for the authorizing certificate. 
This avoids having to invalidate the entire verified-application list when 
a new CCM arrives. 

Referring now to FIGs, 4 and 5, a process for maintaining a list of 
20 third parties certificates is described. A list 34 of trusted third party 
(TTP) certificates is maintained is the SIM 15 or in the mobile device 
10. This list includes the certificates of all third parties that are trusted 
by the user of the communication device 1 0. For example, multiple 
software vendors may be trusted, all authorized by a common root 
25 entity in a common security domain, where the root entity is in position 
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of the root key, the trusted third parties certificates are signed with 
signatures derived from the root key and the TTP list 34 in the nnobile 
device has corresponding digital signatures that it can use to verify the 
signatures of the TTP certificates. 

5 

The list entries in list 34 contain certificate fingerprints in the form 
of hashes of the encoded sign certificates. The full hash output for the 
specified algorithm must be used to generate the fingerprint. A list 
generator checks to insure that no two list entries match when a list is 
10 created. For an X509V3 or X9.68 certificate, the fingerprint hash is 
computed over the ASN.1 encoded signed certificate object, first octet 
to last octet- For WTLS certificates, the hash is computed over the 
signed WTLS certificate in network transmission format, first octet to 
last octet. 

15 

The signature type and length are indicated by the administrator 
certificate, which must be present on the device. If no administrator 
certificate is on the device or the signature does not verify, the 
message is rejected. 

20 

The process of FIG. 4 commences upon a receipt of a new 
certification configuration message in step 502. In step 504, a check is 
performed to check that the CCM is valid. If no administrator certificate 
is present in the mobile communications device 10 or its SIM 15, or if 
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the administrator certificate signature does not verify with the signature 
of the CCM 41 , the message is rejected in step 506. 

Assuming the CCM is valid, the communications device 10 
5 begins a scan through the trusted third certificate party list 34 (step 
510). At the beginning of a scan, a counter "n" is set to one (step 512), 
If, for a given certificate in the TTP list 34, there is no stored fingerprint, 
a fingerprint for that entry "n" is computed in step 514. In step 516, a 
check is carried out to check whether a fingerprint for an authorized 
10 TTP in the CCM message matches a fingerprint in the TTP list 34. If it 
does not match, the certificates in the TTP list 34 is disabled in step 
518. If the fingerprint stored in the list 34 matches the fingerprint 
received in the CCM 41 , the certificate is enabled in step 520. The 
scan continues in a simple loop counter manner by checking step 522 
15 whether the counter n has reached its maximum value N. If not, the 
counter is incremented in step 528 and the next fingerprint is checked 
(with pre-computation of that fingerprint if necessary). When the last 
fingerprint in the list has been checked, the process ends at step 530. 

20 The format of a CCM message is illustrated in FIG. 5. The CCM 

is either periodically fetched from the central controller 21 or 
downloaded by the central controller 21 to the device 10. The following 
is a table of the elements illustrated in FIG. 5. 
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"Version" is the version number of the security specification (e.g. 
version 1) "certificateAdvice" is enumerated { enable-all (0), disable-all 
(1), enable-list (2), disable-list (3) } 

"listLength" is the total length of the following list and must be sent as 
5 zero when certificateAdvice is enable-all or disable-all. 
"hashType" is enumerated { md5 (0), sha-1 (1) } 
"hashLength" is the number of octets output by the selected hash type 
(1 6 for MD5 and 20 for SHA-1 ). 

10 A record must be kept of the domain that authorized a given 

application. If a CCM message is received while applications are 
currently running, a check must be made that any applications no 
longer in the trusted domain have their permissions reconfigured 
appropriately. 

15 

The format for entry in list 34 is: one octet hashType; 2 octets 
permissions; and a number of octets of hash value equivalent in length 
to the hashLength. 

20 There now follows, for completeness, a description of various 

further aspects of certificate management. 

Three type of certificates are provided for: 1.) operator, 2.) 
manufacturer, and 3.) trusted third party. It is not necessary that all 
25 types be present but the operator and manufacturer root certificates 
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must be present for these domains to be enabled. The manufacturer 
may load initial third party certificates on the device. Further 
certificates may be downloaded to the device as signed wireless 
application protocol (WAP) or world wide web (WWW) content. 

5 Downloaded certificates must be verified by an existing trusted 

certificate and are placed in the domain defined by the root certificate 
at the top of the verification chain for the downloaded certificate. Third 
party root certificates should be in protected memory. All third party 
certificates are subject to restrictions imposed by valid certificate 

10 configuration messages. 

New third party root certificates may be downloaded as signed WAP or 
WWW content. The signature on the content should be of a device 
administrator. 

15 The manufacturer root certificate is pre-loaded in protected, 

preferably read only, memory on the device at manufacture time. The 
manufacturer should include a mechanism to re-key the device due to 
key compromise. Since the manufacturer root is preferably in read only 
memory this can be accomplished by having multiple root certificates 

20 stored and switching between them with a proprietary change 
message. 

The operator root certificate is provided on the SIM if support for 
certificate storage on the SIM exists. For legacy SIMs not having such 
storage, the operator root may be downloaded using the root download 
25 procedure described below. 
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Certificates below a given root are installed in files using a 
hierarchical structure corresponding to the structure of the domain. For 
single level domains this is equivalent to a directory for each domain; 
5 multi-level domains require a hierarchical directory structure. 

The actions that can be performed for a given certificate are: 1 .) 
addition, 2.) deletion, 3.) mark trusted, 4.) mark un-trusted, 5.) modify 
fine grain access permissions. The ability to perform these actions 
10 depends no the certificate type being modified as well as the access 
level of the entity performing the operation. Device users may always 
delete, mark trusted or untrusted, or modify fine grain access 
permissions for third party certificates. They may add a third party 
certificate as long as it is certified by an existing trusted certificate. 

15 

For devices using legacy SIM's the following procedure may be 
used to download the operator root certificate. First, upon sign-up with 
an operator the customer is required to call a service provisioning 
number. The operator service center obtains any required information 

20 from the customer and starts the certificate download to the device. 
This download may be accomplished by defining a special SMS 
message type. Once the procedure is complete the device displays 
the hash of the certificate and a transaction identifier; hash 
(certificate/transaction identifier). The hash type used should be the 

25 same as that used for the certificate signature. The customer reads 
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this information back to the operator. If this information is correct the 
provisioning process is complete. Alternative methods to download an 
operator certificate may be used where appropriate but must insure 
that the certificate is received by the device unaltered. 

5 

Accordingly, a method of operation of a mobile communications 
device, has been described, comprising: maintaining a list of 
application programs and, for each application program, a digital 
fingerprint of that application program; upon execution of an application 

10 program, checking the list for an entry that includes the digital 

fingerprint of the application program, and executing the application 
program if the digital fingerprint is present; else performing digital 
signature verification for the application program if the digital fingerprint 
is not present in the list. Other aspects and embodiments of the 

15 invention have been described by way of example only and 

modifications of detail can be made within the scope and spirit of the 
invention. 

We claim: 
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Claims 

1 . A method of operation of a mobile communications device, 
comprising; 

5 maintaining a list of application programs and, for each 

application program, a digital fingerprint of that application program; 

upon execution of an application program, checking the list for an 
entry that includes the digital fingerprint of the application program, and 
executing the application program if the digital fingerprint is present; 
10 else performing digital signature verification for the application 

program if the digital fingerprint is not present in the list. 

2. The method of claim 1 , wherein the executing of the application 
takes place v\/ithout unconditional verification of a digital signature 

15 specific to the application when the digital fingerprint is present. 

3. The method of claim 1 , further comprising not executing the 
application program if the digital fingerprint is present in the list but an 
aging parameter has expired since last occurrence of signature 

20 verification for that application program. 

4. The method of claim 1, further comprising incrementing or 
decrementing an aging count parameter upon execution of an 
application program. 
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5. The method of claim 1 , wherein the step of checking the list 
comprises generating a digital fingerprint for the application program. 

6. The method of claim 1, wherein the method is performed upon 
5 downloading of a new application to the mobile communications 

device. 

7. The method of claim 1 , wherein the list is maintained in secure 
memory. 

10 

8. The method of claim 6, wherein the list is maintained in a 
subscriber identity module removeably coupled with the 
communications device. 

15 9. A communications device comprising: 

a first memory storing a list of application programs and, for each 
application program, a digital fingerprint of that application program; 

a second memory for storing application programs; 

a digital fingerprint generator for generating a digital fingerprint of 
20 an application program prior to its execution; 

a digital fingerprint comparator for comparing a digital fingerprint 
from the digital fingerprint generator with a digital fingerprint from the 
list and for causing execution of the application program if a successful 
comparison is made. 
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10. The communications device of claim 9, further comprising a 
signature verifier for verifying a digital signature of an application if a 
digital fingerprint for the application is not present in the list. 

5 11. The communications device of claim 1 1 , wherein the list is stored 
in a subscriber identity module removeably coupled to the 
communications device. 

12. A method of control of a communications device having a list of 
10 digital certificates, comprising: 

receiving a certificate configuration message including at least 
one digital fingerprint of an encoded digital certificate having a digital 
signature; 

comparing the at least one digital fingerprint with a digital 
15 fingerprint for a corresponding digital certificate stored in the list of 
digital certificates and enabling the corresponding digital certificate in 
the list if there is a successful comparison and disabling the 
corresponding digital certificate if there is no successful comparison. 

20 13. The method of claim 12 further comprising computing a digital 
fingerprint for the corresponding digital certificate if there is no digital 
fingerprint stored in the list when the certificate configuration message 
is received. 
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